home *** CD-ROM | disk | FTP | other *** search
-
- debugging
- -----------------------------
-
- render.library provides a rather strict debugging strategy.
- the internal error manager looks like this:
-
- if (parameter_in_valid_range)
- {
- ...
- }
- else
- {
- Exception_ILLEGAL();
-
- /* causing a $80000004 software failure */
- }
-
- it might appear strange at first sight, but this technique has
- enormous advantages for you and me. invalid parameters have got
- few chance to infiltrate the code and play havoc where it becomes
- really dangerous and hard to understand.
-
- the illegal exception (caused by an ILLEGAL opcode) is a 'clean'
- crash without further damage, and it can easily be catched with
- debuggers.
-
- so this exception might become your worst enemy when programming
- render.library. if you encounter dozens of $80000004 requesters
- and can't get rid of them, it is very likely that the problem sits
- in front of your computer.
-
- this can easily drive you berzerk especially with DeleteRMHandler().
- that's another reason why it's highly recommended to use a
- memhandler whenever possible: you get a built-in memory-deallocation
- reminder for free. if DeleteRMHandler() crashes with an ILLEGAL
- exception, you know exactly that you forgot to free memory, or to
- delete a render.library instance such as palettes, histograms, or
- engines.
-
- this debugging concept is not provided with every function, though,
- but maybe i will apply it to more or even all functions in the future.
- it proved to be a very reliable error treatment, since it just cannot
- be ignored.
-